Two main attributes of the modern intelligent public switched telephone network are its flexibility and accessibility. The network's flexibility allows local exchange carriers to more easily implement new network subscriber services at the local exchange carrier databases. The network's flexibility also allows the physical components of the network to vary according to particular subscriber needs and network applications. In addition, the network's accessibility will allow, subsequent to future action by the Federal Communications Commission and state public service commissions, third party providers such as cable companies and cellular communications companies (hereinafter referred to as Other Service Providers, or OSPs), to access local exchange carrier databases, usually after negotiating with the local exchange carrier for an allowed amount of network traffic flow.
The underlying reason for the network's flexibility and accessibility lies in its system architecture--the Advanced Intelligent Network (AIN) architecture. Ever since its development and subsequent deployment, the AIN architecture has allowed new network services to be introduced by local exchange carriers more rapidly and with fewer associated development costs than earlier networks. At the same time, it has allowed the local exchange carriers to more easily manage such services. Not surprisingly, subsequent to the deployment of this open architecture, local exchange carriers successfully introduced a myriad of new network services to network subscribers in the past few years, and OSPs are expected to provide many more upon opening of the AIN.
As a result of the introduction of this myriad of new network services, the flow of network traffic at various levels of the network will increase substantially, and, as OSPs begin to provide an increasing number of services, the need to effectively monitor and control network traffic will become a necessity to prevent network overload and to ensure that traffic associated with particular OSPs does not exceed negotiated rates.
In light of the above, and in order to fully understand the need for the present invention, it is first necessary to understand the basic architecture of the AIN. FIG. 1 is a block diagram of the AIN environment and shows the components of the AIN generally at 10. These components contain most of the intelligence in the network and are well known to those skilled in the art.
Each of a plurality of central office switches is equipped with a service switching point (SSP) node on the Advanced Intelligent Network. A plurality of representative SSPs are shown as 12a-12c in FIG. 1. Those skilled in the art will recognize that each service switching point is the Advanced Intelligent Network component of a typical electronic central office switch as used by a local exchange carrier. The dashed lines between SSPs in FIG. 1 indicate that an arbitrary number may be associated with the network operated by any given local exchange carrier. Each of the SSPs 12a-12c is equipped with appropriate hardware and software for the generation of triggers in response to activity on dialing lines and for accepting instructions from service control points and elsewhere in the Advanced Intelligent Network. Emanating from each central office associated with SSPs 12a-12c are respective subscriber lines 14a-14c, which are terminated by respective telephone sets 17a-17c. Typically, each central office switch associated with an SSP will be connected to 10,000-70,000 subscriber lines. A particular subscriber number within the network is associated with a connection through a particular one of subscriber lines 14a-14c. Thus, each SSP will generate appropriate triggers that include information identifying the particular subscriber line when a piece of customer premises equipment 17a-17c connected to the line goes off hook, commences dialing, etc. The nature and format of such triggers is known to those skilled in the art and is specified in the Signaling System 7 (SS7) protocol.
It should be understood that telephone sets 17a-17c are generalized representations of terminating customer premises equipment. Therefore, in addition to conventional telephone sets, devices such as facsimile machines, automatic dialers, and the like can also be connected to subscriber lines. Furthermore, it should be understood that certain call rerouting functions implemented through the Advanced Intelligent Network can cause a particular subscriber number to be temporarily associated with a different subscriber line other than that with which it is normally associated. For example, implementation of call forwarding through the network when the Advanced Intelligent Network completes a call to a particular subscriber number to a different subscriber line, based on instructions issued by the user of the subscriber number, will temporarily associate calls to a subscriber number with a different subscriber line.
The central offices associated with the SSPs 12a-12c in turn communicate with each other through a plurality of trunk circuits indicated at 18a and 18b in FIG. 1. These trunk circuits interconnect the central offices and are the voice path trunks that connect communications when completed. It is to be understood that a network communication may be an ordinary telephone call, a data transmission, or any other type of message generated by a calling party over the network and directed to a telephone number of a called party also on the network. It should also be understood that, in a typical network, the trunk circuits 18a and 18b do not represent the only connection paths among the central offices associated with SSPs 12a, 12b and 12c. The Advanced Intelligent Network keeps track of line status and can complete a call through trunk circuits through remote central offices if no direct connection between the central office connected to the originating subscriber line and the central office connected to the terminating subscriber line is available.
Data links 22a, 22b and 22c respectively connect SSPs 12a, 12b and 12c to a local signal transfer point (STP) 20. These data links are typically 56 kilobit per second bi-directional data links using the Signaling System 7 (SS7) protocol. This SS7 protocol is well known to those skilled in the art and is described in a specification available through the American National Standards Institute (ANSI). The SS7 protocol is a layered protocol; each layer provides services for layers above it and relies on layers below it for services. The protocol employs packets with beginning and terminating flags and a check bit. The packets also provide a signal information field with variable length user specific data and a routing label. The packets further provide a service information octet that identifies a priority of the message, the destination of the message on a national network level, and the user name identifying the entity that created the message. The packets also include control and sequence numbers with uses and designations well known to those skilled in the art and described in further detail in the aforementioned ANSI specification.
SS7 data packets generated by the SSPs 12a, 12b and 12c are sent from the SSPs to the STP 20. A signal transfer point such as the STP 20 is not normally the end destination of these packets; rather, it is a multi-port high speed switch programmed to direct traffic among the other components in the network. The STP 20 switches the packets in response to routing information contained in the layered protocol of the packets conveyed over data links 22a, 22b and 22c. It should also be noted that service transfer points such as STP 20 are installed in redundant pairs to ensure uninterrupted service over the network should one of the STPs in the pair fail.
The local STP 20 is in turn connected, through SS7 data link 26, to a local service control point (SCP) 24 of the type well known to those skilled in the art. Service control points such as the SCP 24 are implemented by powerful, relatively fault tolerant computers such as the Star Server FT Model 3200 or the Star Server FT Model 3300, both sold by American Telephone & Telegraph Company. The architectures of these computers are based on Tandem Integrity S2 and Integrity S1 platforms, respectively. These computers have from 1 to 27 disk drives in sizes ranging from 300 megabytes to 1.2 gigabytes per drive and main memory ranging from 24 to 192 megabytes. This processing power allows the computers to execute up to 17 million instructions per second. With SS7 protocol, this equates to 50 to 100 transactions (query/response pairs) of network messages per second. As with the aforementioned STPs, these SCPs are implemented in redundant pairs to ensure continued operation of the network in the event that one of the SCPs in the pair fails.
Service control points contain much of the intelligence necessary to implement the limited access features associated with the present invention. For example, the SCP 24 contains subscriber databases associated with subscriber numbers connected to SSPs 12a, 12b and 12c. When a communication is placed from a particular subscriber number, several triggers are defined at the associated SSP for that particular communication. Each trigger generates a data packet and sends it to the SCP 24. Each trigger prompts the SCP to query a database containing customized communication handling instructions subscribed to by particular subscriber numbers. The SCP 24 determines what types of specialized processing instructions, if any, to implement in association with the communication. The packet may instruct the SSP to route the communication in accordance with specialized communication handling instructions or to route the communication in a manner commonly known to those skilled in the art as Plain Old Telephone Service (POTS), depending upon the database instructions particular to each subscriber number.
The SCP databases are updated with information provided from a Service Management System (SMS) 28 through SS7 data link 27. The SMS 28 is also implemented by a powerful general purpose digital computer. When a subscriber modifies his or her customized communication handling instructions, the SMS 28 updates the subscriber features by downloading this new information to the databases at the SCP 24 through data link 27. The SMS 28 also downloads, on a non-real-time basis, billing information needed to invoice subscribers for the customized features provided.
The SMS 28 is also connected to and services a service node (SN) 30 via data link 31. As shown in FIG. 1, the service node 30 is typically connected to only a few SSPs via integrated service digital network (ISDN) links shown at 32. This service node is of the type well known to those skilled in the art and is implemented by the same types of computers that implement the SCP 24. The SN 30 includes the database and computing capabilities possessed by the SCP 24. In addition, the SN 30 also includes voice and DTMF signal recognition and voice synthesis capabilities. Thus, while the physical embodiments of the SCP 24 and the SN 30 are similar, their functions are different. While service control points normally implement database inquiry and routing services that occur prior to completion of a communication (providing a ringing signal to the called subscriber and a ring back to the calling subscriber), service nodes such as SN 30 are used to implement communication handling instructions requiring an audio connection or to facilitate transfer of a large amount of data during or subsequent to a communication placed over the network. Thus, services implemented during a communication usually require the use of a service node.
The network also includes a regional STP 33, connected to the local STP 20 via an SS7 data link (not shown), and a regional SCP 34, connected to the regional STP 32 and the SMS 28 through SS7 data links (not shown). Information downloaded to the local STP 20 and the local SCP 24 is also supplied to these regional devices. These regional devices thus allow subscriber communication handling instructions associated with particular subscriber numbers to be implemented on a network-wide basis regardless of the physical location of the subscriber number in the network.
Currently, an Automatic Code Gap (ACG) program is implemented at the SCP level to reduce the flow of traffic to the SCP 24 from the SSPs. The program may be automatically initiated by the SCP based upon certain activation criteria, or it may be manually activated by a Network Manager. The ACG program may also be initiated either selectively to control a particular customer or service or non-selectively to control the flow of all traffic supported by the SCP. If the ACG is being initiated selectively, the ACG program is implemented by associating a code on which the ACG is to be activated with a controlled entity such as a subscriber, a service, or an SCP. The ACG program operates on a response basis, such that, upon the program being activated at the SCP in one of the two ways mentioned above, the SCP forwards an ACG traffic-control message to the ACG-supported SSPs. The traffic-control message causes the SCP to regulate the flow of traffic to the SCP to protect the SCP from overloads.
However, in a mediated network environment, three network traffic control problems will arise in such a network when OSP service control points are implemented in conjunction with a mediated access service control point. These problems, as discussed below, make the use of an ACG for inter-SCP traffic control impractical and obsolete. First, the destination of a query is unknown until the MA SPA implemented at the SCP translates the query. Thus, when OSP SCPs are implemented in a mediated network environment, it will not be practical to activate an ACG program to control network traffic to the OSP SCP at the SSP level because an SSP will be incapable of determining an OSP SCP query destination. The SPA must complete its translation at the SCP in order for the query destination to be determined. The ACG program at the SSP will not be capable of selectively reducing the query rate to an OSP SCP because the SSP does not know the final destination of the query. In other words, the intermediate point for a query being processed from an SSP to an OSP SCP is a MA SCP. The routing data for the query is contained within the MA SCP, but not in the SSP. Therefore, the MA SCP knows the final destination (the appropriate OSP SCP) for a query while the SSP does not. Based upon these parameters, the inefficiency and ineffectiveness of activating an ACG program at the SSP level is obvious to one skilled in the art.
Second, the ACG program will be ineffective in regulating traffic between the SSPs and the OSP SCPs due to the reshaping of the query traffic at the SCP. When the SCP functions as a mediated access point, it alters the arrival characteristics of the traffic to the OSP SCPs due to associated interprocessing delays. As a result, the SCP effectively initiates new traffic streams to the OSP SCPs. Reduction in query traffic thus has to be done at the point at which traffic streams are initiated for the OSP SCPs--the MA SCP. If the ACG program is used to regulate OSP SCP traffic at the SSP level, over controlling or under controlling of the traffic to the OSP SCPs may result, as the traffic would be controlled at both the SSP and the SCP level. It is much more efficient to regulate traffic to a destination from the immediate or closest source to that destination. The closest source of traffic for an OSP SCP is the MA SCP and, therefore, it is more efficient to regulate traffic to the OSP SCP from the MA SCP.
Third, the ACG program will be ineffective in enforcing traffic rates negotiated between the local exchange carrier and the OSPs. It is difficult to enforce the negotiated traffic rates because using ACG is not an exact method, it is only an approximation. It is also difficult to implement an instantaneous maximum and sustainable average for query traffic using an ACG program. OSPs negotiate traffic rates with local exchange carriers who own and service the SCP. When such traffic rates are negotiated, it is desirable that the operator ensures that the negotiated traffic rate is sustained over a specified length of time, given that the demand for the services provided by the OSPs exists. The ACG program provides no means for sustaining these negotiated rates over periods of time.
In summary, the Automatic Code Gapping program that is normally used at the SSP level to control traffic flow to the SCP will not be as effective in a mediated environment due to the reasons set forth above.
Thus, there is a need in the art for a methodology of regulating traffic flow from a SCP to associated OSP SCPs in a mediated network environment in a manner that addresses the above needs. In particular, it is desirable to have a system that can regulate this traffic at the SCP level, as opposed to the SSP level, in order to prevent severe over or under controlling of such traffic. Furthermore, there is a need for a system that can regulate traffic on the SCP level while allowing a local exchange carrier to have full control over the network traffic through its SCP. In addition, there is a need for a system with a traffic control and management mechanism to ensure that the traffic flow to the OSP SCPs matches the negotiated traffic rates by reducing excessive traffic to an OSP SCP. Further, there is a need for providing for the surveillance of the traffic rates for each OSP SCP without using a large amount of SCP processing capacity thereby minimizing extra delays in the network.